iiiiiiiiiiniiiiiiiiiiii 

US006757825B1 

(12) United States Patent m Patent No.: us 6,757,825 bi 

MacKenzie et al. (45) Date of Patent: Jun. 29, 2004 



(54) SECURE MUTUAL NETWORK 
AUTHENTICATION PROTOCOL 

(75) Inventors: Philip DougJas MacKenzie, 
Maplewood, NJ (US); Ram 
Swaminathan, New Providence, NJ 
(US) 

(73) Assignee: Lucent Technologies Inc., Murray Hill, 
NJ (US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C 154(b) by 0 days. 

(21) AppL No.: 09/353,468 

(22) Filed: Jul. 13, 1999 

(51) Int. CI. 7 H04L 9/30 

(52) U.S. CI 713/169; 713/200; 713/201; 

713/171; 713/155; 380/285; 380/30; 340/5.1 

(58) Field of Search 713/171, 155, 

713/169, 168, 200, 201, 202; 380/285, 
283, 28, 30, 44; 340/5.1 

(56) References Cited 

U.S. PATENT DOCUMENTS 



5,241,599 A 8/1993 Bellovin et al 380/21 

5,440,635 A 8/1995 Bellovin et al 380/25 

6,088,805 A * 7/2000 Davis et al 713/202 

6,134,327 A * 10/2000 Van Oorschot 380/30 

6,226,750 Bl * 5/2001 Trieger 713/201 

6,275,941 Bl * 8/2001 Saito et al 713/201 

6,385,318 Bl * 5/2002 Oishi 380/262 

6,438,691 Bl * 8/2002 Mao 713/176 

6,446,206 Bl * 9/2002 Feldbaum 713/175 

6,496,932 Bl * 12/2002 Trieger 713/168 

6,550,011 Bl * 4/2003 Sims, III 713/193 

6,567,915 Bl * 5/2003 Guthery 713/168 



OTHER PUBLICATIONS 

H. Dobbertin, A. Bosselaers, and B. Preneel, "RIP- 
EMD-160: A Strengthened Version of RIPEMD", Fast 



Software Encryption, LNCS 1039, Springer-Verlag, 1996, 
pp. 71-82. 

"Secure Hash Standard", Federal Information Processing 
Standards Publication (Supersedes FIPS PUB 180— May 
11, 1993), U.S. Department of Commerce, Technology 
Administration, National Institute of Standards and Tech- 
nology, Issued Apr. 17, 1995. 

W. Diffie and M. E. Hellman, "New Directions in Cryptog- 
raphy", IEEE Transactions On Information Theory, vol. 
IT-22, No. 6, Nov. 1976, pp. 644-654. 
R. L. Rivest, A. Shamir and L. Adleman, "A Method for 
Obtaining Digital Signatures and Public-Key Cryptosys- 
tems", Communications oftheACM, Feb. 1978, vol. 21, No. 
2, pp. 120-126. 

(List continued on next page.) 

Primary Examiner— Ly V Hua 

(57) ABSTRACT 

A password-only mutual network authentication protocol 
and key exchange protocol using a public key encryption 
scheme in which a server generates a public key/secret key 
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Otherwise, the client rejects authentication. If the protocol is 
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an alternate embodiment, as a function of the public key and 
a function of a password). If the public key space mapping 
function F PK applied to p, F Pi ^(p), is an element of the public 
key message space, then the protocol continues. If F P/c (p) is 
not an element of the public key message space, then the 
client determines to reject authentication, but continues with 
the protocol so that the server does not gain any information 
about the password. If the client determines to reject 
authentication, it will terminate the protocol at a later step at 
which time the termination of the protocol cannot leak any 
sensitive information. If both the client and the server accept 
authentication, then session keys are generated for subse- 
quent secure communication between the client and server. 
Specific embodiments are disclosed in which RSA is used as 
the public key encryption scheme. 
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FIG. 1 B 
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FIG. 2 A 
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FIG. 3 B 
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FIG. 4 k 
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SECURE MUTUAL NETWORK 
AUTHENTICATION PROTOCOL 

FIELD OF THE INVENTION 

The present invention relates generally to network authen- 
tication and key exchange. More particularly, the present 
invention relates to a password -only secure mutual network 
authentication and key exchange protocol. 

BACKGROUND OF THE INVENTION 

Authentication over a network is an important part of 
security for systems that allow remote clients to access 
network servers. Authentication is generally accomplished 
by verifying one or more of the following: 

something a user knows, e.g. a password; 

something a user is, i.e., biometric information, such as a 
fingerprint; and 

something a user has, i.e., some identification token, such 
as a smart-card. 
For example, an automatic teller machine (ATM) verifies 
two of these: something a user has, the ATM card, and 
something a user knows, a personal identification number 
(PIN). ATM authentication is significantly easier than 
authentication over a data network because the ATM itself is 
considered trusted hardware, such that it is trusted to verify 
the presence of the ATM card and to transfer the correct 
information securely to a central transaction server. 

In addition to authentication, key exchange is an impor- 
tant part of communication across a data network. Once a 
client and server have been authenticated, a secure commu- 
nication channel must be set up between them. This is 
generally accomplished by the client and server exchanging 
keys for use during communication subsequent to authenti- 
cation. 

Authentication over a data network, especially a public 
data network like the Internet, is difficult because the com- 
munication between the client and server is susceptible to 
many different types of attacks. For example, in an eaves- 
dropping attack, an adversary may learn secret information 
by intercepting communication between the client and the 
server. If the adversary learns password information, the 
adversary may replay that information to the server to 
impersonate the legitimate client in what is called a replay 
attack. Replay attacks are effective even if the password sent 
from the client is encrypted because the adversary does not 
need to know the actual password, but instead must provide 
something to the server that the server expects from the 
legitimate client (in this case, an encrypted password). 
Another type of attack is a spoofing attack, in which an 
adversary impersonates the server, so that the client believes 
that it is communicating with the legitimate server, but 
instead is actually communicating with the adversary. In 
such an attack, the client may provide sensitive information 
to the adversary. 

Further, in any password based authentication protocol, 
there exists the possibility that passwords will be weak such 
that they are susceptible to dictionary attacks. A dictionary 
attack is a brute force attack on a password that is performed 
by testing a large number of likely passwords (e.g. all the 
words in an English dictionary) against some known infor- 
mation about the desired password. The known information 
may be publicly available or may have been obtained by the 
adversary through one of the above described techniques. 
Dictionary attacks are often effective because users often 
choose easily remembered, and easily guessed, passwords. 
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There are various known techniques for network authen- 
tication. These known techniques will be divided into two 
classifications. The first classification includes those tech- 
niques that require persistent stored data on the client 
5 system. The second classification includes those techniques 
which do not require persistent stored data on the client 
system. 

With respect to the first classification, persistent stored 
data may include either secret data (e.g. secret keys shared 

10 with the authenticating server) which must never be 
revealed, or non-secret but sensitive data (e.g. the authen- 
ticating server's pub He key) which must be tamper-proof. 
With either type of persistent data, extra security require- 
ments are necessary to secure the data from attack from an 

15 adversary. Further, when using an authentication protocol 
which relies on both passwords and persistent stored data, a 
compromise of either may lead to a vulnerability of the 
other. For example, compromising a secret key may lead to 
a possible dictionary attack on the password. Another prob- 

20 lem with this first class of protocols is that persistent stored 
data requires generation and distribution of keys, which can 
be cumbersome, and generally provides a less flexible 
system. 

The second classification is called password-only authen- 

25 tication protocols because there is no requirement of per- 
sistent stored data at the client. The client only needs to be 
able to provide a legitimate password. The notion of pro- 
viding strong security and authentication using potentially 
weak passwords seems to be contradictory. However, there 

30 exist several password-only user authentication and key 
exchange protocols that are designed to be secure. A descrip- 
tion of these protocols may be found in D. Jablon, Strong 
Password-Only Authenticated Key Exchange, ACM Com- 
puter Communication Review, ACM SIGCOMM, 26(5): 

35 5-20,1996. Some of the more notable of these password- 
only protocols includes Encrypted Key Exchange (EKE) 
described in S. M. Bellovin and M. Merritt, Encrypted Key 
Exchange: Password-Based Protocols Secure Against Dic- 
tionary Attacks, Proceedings of the IEEE Symposium on 

40 Research in Security and Privacy, pp. 72-84, 1992; 
Augmented-EKE (A-EKE), S. M. Bellovin and M. Merritt, 
Augmented Encrypted Key Exchange: A Password-Based 
Protocol Secure Against Dictionary Attacks and Password 
File Compromise, Proceedings of the First Annual Confer- 

45 ence on Computer and Communications Security, 1993, 
pages 244-250; Modified EKE (M-EKE), M. Steiner, G. 
Tsudik, and M. Waidner, Refinement and Extension of 
Encrypted Key Exchange, ACM Operating System Review, 
29:22-30, 1995; Simple Password EKE (SPEKE) and 

50 Diffie-Hellman EKE (DH-EKE), both described in D. 
Jablon, Strong Password-Only Authenticated Key Exchange, 
ACM Computer Communication Review, ACM 
SIGCOMM, 26(5):5-20,1996; Secure Remote Password 
Protocol (SRP), T. Wu, The Secure Remote Password 

55 Protocol, Proceedings of the 1998 Internet Society Network 
and Distributed System Security Symposium, pages 97-111, 
1998; and Open Key Exchange (OKE), Stefan Lucks, Open 
Key Exchange: How to Defeat Dictionary Attacks Without 
Encrypting Public Keys, Security Protocol Workshop, Ecole 

60 Norm ale Sup'erieure, Apr. 7-9, 1997. 

The problem with these known password-only authenti- 
cation protocols is that they have not been proven secure. In 
fact, the EKE protocol may be susceptible to certain number 
theoretic attacks as described in S. Patel, Number Theoretic 

65 Attacks on Secure Password Schemes, Proceedings of the 
IEEE Symposium on Research in Security and Privacy, 
pages 236-247, 1997. In view of the importance of network 
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security, there is a need for a password-only mutual authen- 
tication protocol which is pro v ably secure. 

SUMMARY OF THE INVENTION 

The present invention provides a secure password-only 
mutual network authentication protocol utilizing a public 
key encryption scheme. The particular public key encryption 
scheme used to implement the protocol must be a so-called 
usable encryption scheme, as defined below. A network 
server generates public key/secret key pairs in accordance 
with the public key encryption scheme and transmits a 
public key to a client. The client determines whether the 
received public key is an element of a so-called testable 
superset (as defined below) of the set of all public keys of the 
public key encryption scheme. This determination is able to 
be made because of the requirement that the public key 
encryption scheme be usable. The determination by the 
client as to whether the public key is an element of a testable 
superset provides the client with a technique for determining 
whether the server has provided a public key which was 
chosen in an appropriate manner. If the public key is found 
not to be within the testable superset, then authentication is 
rejected by the client. Otherwise, the protocol continues. 

In one embodiment of the invention, the client and server 
are both in possession of a password which is used for 
authentication purposes. In this embodiment, the client 
continues the protocol by generating a parameterp as a 
function of at least the public key and password. If the public 
key space mapping function, F PK , applied to p, F PX (p), is an 
element of the so-called message space of the public key, 
then the protocol continues by the client encrypting a 
substantially random element of the message space of the 
public key using the public key and performing the group 
operation of the public key message space on the result and 
F P/c (p). Alternatively, if F^^) is not an element of the 
message space, then the client determines to reject authen- 
tication. However, if the client were to notify the server of 
the rejection at this point, the server may be able to extract 
some useful information about the password. As such, 
although the client has determined to reject authentication, 
the client continues with the protocol so as not to leak any 
information to the server. The client rejects authentication 
later in the protocol at which time the server cannot gain any 
useful information about the password. 

In a second embodiment of the invention, in order to 
protect against a security compromise at the server, the 
server is not in possession of the password, but instead is 
provided with, and stores, a value which is a function of the 
password. The password itself cannot be determined from 
the value stored at the server. 

Third and fourth embodiments of the invention utilize the 
RSA encryption scheme as a usable public key encryption 
scheme. In accordance with these embodiments, RSA spe- 
cific tests are provided for determining whether the server 
provided public key is an element of the testable superset of 
the set of all RSA public keys. In addition, RSA specific tests 
are provided for determining whether certain values are 
elements of the RSA message space. In the third 
embodiment, the server stores the shared password. In the 
fourth embodiment, the server stores a value which is a 
function of the password. 

The inventors have proven that a mutual authentication 
protocol in accordance with the present invention is as 
secure as the underlying public key encryption scheme. 
Thus, in the RSA specific embodiments, the inventors have 
proven that the protocol is as secure as the RSA encryption 
scheme. An outline of the proof is provided. 



,825 Bl 

4 

These and other advantages of the invention will be 
apparent to those of ordinary skill in the art by reference to 
the following detailed description and the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGS. 1A-1B show an embodiment of the authentication 
protocol in which the server stores the password; 

FIGS. 2A-2B show an embodiment of the authentication 
protocol in which the server stores a value which is a 
function of the password; 

FIGS. 3A-3B show an RSA specific embodiment of the 
authentication protocol in which the server stores the pass- 
15 word; and 

FIGS, 4A-4B show an RSA specific embodiment of the 
authentication protocol in which the server stores a value 
which is a function of the password; 

20 DETAILED DESCRIPTION 

Cryptography is a well known technique for providing 
secure communication between two parties. Prior to describ- 
ing the various embodiments of the present invention, some 
background and basic terminology will be provided. 

25 We will first describe encryption schemes. In private key 
encryption schemes, a message m may be encrypted using 
an encryption function E and a secret key K in order to 
generate a ciphertext C. This is represented as C=E^m). The 

3Q ciphertext C may be securely transmitted between two 

30 parties who share the secret key K. The ciphertext may be 
decrypted using a decryption function D and the secret key 
K in order to recover the original message m. This is 
represented as m^Dj^C). 

35 In public key encryption schemes, there exist public key 
(PK) and secret key (SK) pairs (PK, SK). The public key is 
not secret, and anyone may encrypt a message m using the 
public key to create ciphertext C such that C=E / > K (m). The 
ciphertext can only be decrypted using the secret key such 

40 that m^D^C). The ciphertext cannot be decrypted using 
the public key. Public key cryptography is well known in the 
art. 

One well known public key encryption scheme is RSA, 
which is described in R. Rivest, A. Shamir, L. Adleman, A 

45 Method for Obtaining Digital Signature and Public Key 
Cryptosy stems, Communications of the ACM, vol. 21, 
120-126, 1978. In RSA, the public key is (N,e) and the 
secret key is (N,d), where N is the product of two large 
randomly chosen primes p and q (i.e., N«p q), e is an 

so arbitrary number greater than 2 such that the greatest com- 
mon divisor of e and (p-l)'(q-l) is 1, and d«e -1 mod(p- 
l)-(q-l). The encryption function is E(m)=m' mod N and 
the decryption function is D(C)=C* mod N. 

We now discuss some other cryptographic terminology. 

55 Informally, a function /from a set S to a set T is a one-way 
function if f(x) is easy to compute for all x in S but for most 
y in T, it is computationally infeasible to find any x in S 
where j ? (x)=y. One example of a one-way function is modu- 
lar exponentiation. Let p be a large prime and g a generator 

60 of the multiplicative group mod p (that is, the numbers in the 
range 1, . . . , p-1). Then ;f(x)=g* mod p is generally assumed 
to be a one-way function. The inverse function, called the 
discrete log function, is difficult to compute. There are also 
other groups in which the discrete log function is difficult to 

65 compute, such as certain elliptic curve groups. A key 
exchange protocol called Diffie-Hellman Key Exchange and 
described in W. Diffie and M. Hellman, New Directions in 
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Cryptography, IEEE Transactions on Information Theory, 
vol. 22, no. 6, 644-654, 1976, is based on this function. 
Specifically, two parties Alice and Bob agree on a secret key 
as follows: Alice chooses a random x and sends X=g* mod 
p to Bob, while Bob chooses a random y and sends Y^g* 1 
mod p to Alice. The secret key can be computed by Alice as 
Y* mod p, and by Bob as X* mod p. Note that Y*=X^g^ 
mod p. Diflie-Hellman key exchange can also be performed 
over other groups in which the discrete log function is 
difficult to compute, such as certain elliptic curve groups. 
Informally, a function h from a set S to a set T will be called 
a random hash function if the output of h looks random or 
at least is unpredictable until the function is computed with 
an input x in S. Known functions that generally behave this 
way are SHA-1, described in FIPS 180-1, Secure Hash 
Standard, Federal Information Processing Standards Publi- 
cation 180-1, 1995; and R1PEMD-160, described in H. 
Dobbertin, A. Bosselaers, B, Preneel, RIPEMD-160: a 
strengthened version of RIPEMD, In Fast Software 
Encryption, 3rd Intl. Workshop, 71-82, 1996. 

In general, cryptographic schemes have security param- 
eters which describe their level of security. We will use k as 
the security parameter for hash functions (where 



l 

¥ 



15 



20 



25 



is assumed to be negligibly small), and we will use 1 as the 
security parameter for public key encryption schemes, and in 
particular we will assume the RSA modulus N will be 1 bits 
long. 

A mutual authentication protocol in accordance with a 
first embodiment of the invention is shown in FIGS. 1A-1B. 
Steps shown on the left side of the figure are performed by 
a server and steps shown on the right side of the figure are 
performed by a client. Arrows represent communication 
between the client and the server. In accordance with the 
protocol, the server will authenticate itself to the client and 
the client will authenticate itself to the server. After both 
sides have authenticated, each will generate a secret key, 
called a session key, which may be used for subsequent 
secure communication. 

Prior to initiation of the protocol it is assumed that the 
client and the server are in possession of certain information. 
The server generates public key/secret key pairs (PK, SK) in 
accordance with the particular public key encryption scheme 
being used. The generation of public key/secret key pairs is 
well known in the art and will not be described herein. The 
server and client are both in possession of a password x (i.e., 
a shared secret) which the client uses to authenticate with the 
server. The password or must be set up in advance between 
the client and the server, and should be chosen indepen- 
dently for each client-server pair, or chosen in such a way as 
to be unique for each client-server pair. 

It is noted that the following protocol authenticates both 
the server and the client. Thus, neither the server nor the 
client are assumed to be authentic, and thus either the server 
or the client may be an adversary. The client may be an 
adversary attempting to authenticate itself and gain access to 
the server. The server may be an adversary attempting to 
spoof another authentic server in an attempt to gain sensitive 
information from an unsuspecting client. 

As would be readily apparent to one of ordinary skill in 
the art, the server and client may be implemented as pro- 
grammed computers operating under control of computer 
program code. The computer program code would be stored 
in a computer readable medium (e.g. a memory) and the 



code would be executed by a processor of the computer. 
Given this disclosure of the invention, one skilled in the art 
could readily produce appropriate computer program code in 
order to implement the protocols described herein. The 
5 client and server communicate with each other via a data 
network. Such networked programmed computers are well 
known in the art and will not be described in further detail 
herein. 

Referring now to FIGS. 1A-1B, upon initiation of the 
10 protocol, in step 110 the server generates m, which is a 
random element of the set Q. Q represents a set which is 
large enough to ensure that the probability of generating two 
equivalent m values is negligible. Q may be of a form to 
allow for subsequent key exchange. In step 112, the server 
transmits m and PK to the client. As stated above, it is 
assumed that the server has generated (PK, SK) pairs prior 
to initiation of the protocol. In step 114 the client determines 
whether the m received from the server in step 112 is in the 
set Q and whether PK is in a set e' (which is described in 
detail below). If either of the tests is false, then the client 
rejects authentication. The test of step 114 is performed by 
the client because an adversary spoofing the legitimate 
server may choose m and PK in such a manner that, if the 
client proceeds with the protocol, the adversary could learn 
some information about the password n. 

At this point, a description of what is meant by PK being 
in the set e is provided. As stated above, in order for the 
protocol to operate correctly and not leak any sensitive 
information, the public key/secret key pair (PK, SK) must be 
chosen in an appropriate manner in accordance with the 
particular public key encryption scheme being used. Given 
a particular public key encryption scheme, it would be ideal 
to be able to determine whether the PK received from the 
server in step 112 is an element of the set e of all possible 
public keys that may be generated using that particular 
public key encryption scheme. However, there is no known 
public key encryption scheme (with all the properties 
required for the protocol) which would allow this determi- 
nation to be made within a reasonable time period. Thus, we 
define a usable public key encryption scheme and a testable 
superset e' as follows: 

A public key encryption scheme is usable if there exists a 
testable superset c' of e such that: 

1 . for all PK Ee', \S PJ ^ is superpolynomial in k, where S PK 
represents the set of all possible messages that can be 
encrypted using PK and the encryption of all such 
possible messages. We call this set SPK the message 
space of the public key (PK). 

2. there is a polynomial-time algorithm to determine for 
any PK whether PK Ee'; 

3. for all PK Ee', there is an expected polynomial- time 
algorithm to uniformly draw an element from S PK ; 

4. for all PK there is a polynomial time algorithm to 
determine for any value a, if a ES PK ; and 

5. for all PK Ee', there exists an integer Tj^l+k, a 
polynomial- time computable public key space mapping 
finction F PK with domain {0,1 J* 1 , and a partition of that 
domain into X PA U . . . UX P ^ UZp^UZp^the par- 
tition depends only on PK) such that: 

(a) s PK can be computed in polynomial-time, 

(b) F PKf X PKti -*S PK is 1-1 and onto, for i E{1, . . . , s PK }, 
(i.e. F^ includes a bijection from each set X PKi to 
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(c) for each a ES^ and i E{1, 



s pk}> tnere is a 



polynomial — time algorithm to find x EX PK i so that 
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(d) given x £{0,1 Y 1 , there are polynomial — time algo- 
rithms to test if x SZ PK or x EZ'^, 

(e) for each x EZ PK , Fp^x) $8 PK , 

(f) lZ'pjJ/2 11 is negligible with respect to the security 
parameter k, and 

(g) if E Ee, then with respect to the 
security parameter k. 

We note that the definition of usable could be readily 
extended by one skilled in the art to include encryption 
schemes in which the set of messages that can be encrypted 
using PK is not equal to the set of encrypted messages. One 
skilled in the art could readily modify the protocols 
described herein for use with such an encryption scheme. 
Thus, with respect to the public key PK, the test in step 114 
determines whether PK is an element of the testable superset 
e' of e. If the test in step 114 is false (i.e., m is an element 
of and PK is an element of e') then authentication 
continues. However, if the test in step 114 is true (i.e. m is 
not an element of Q or PK is not an element of e') then 
authentication is rejected by the client because the server has 
chosen PK and/or m in an improper manner. 

In step 116, the client sets parameter {i to be a random 
element of the set Q. In step 118, the client sets parameter 
a to be a random element of the message space S PK . In step 
120, the client calculates parameter p as a random hash 
function H of parameters (PK,m^,Jt). The hash function H, 
may be any random hash function as described above that 
outputs a sufficient number of bits (at least r\). 

In step 122 it is determined whether the public key space 
mapping function, F^, applied to p, F^p), is an element 
of the message space S PK . If F^j^p) is not an element of S PK , 
then authentication should be rejected. However, if it is 
determined in step 122 that F PIi /[p) g S^, it is undesirable to 
terminate authentication at this point because an adversary 
server may gain some knowledge of the password or if the 
client terminates authentication at this point. Therefore, it is 
desirable that the client continue the protocol with the server, 
even if the client has decided that it will reject authentica- 
tion. Thus, if the test in step 122 is true, then the client sets 
q=a. By setting sets q«a, where a was chosen in step 118 as 
a substantially random element of the message space, an 
adversary server will not gain any information about the 
password Jt. If it is determined in step 122 that F PiC (p) SS PKi 
then the client will move forward with the authentication 
protocol by calculating q=E i > iC (a)oF J , /t (p). Thus, a is 
encrypted using the public key with F PK (p) being applied to 
the resulting encryption using the group operation of the 
public key message space. In step 124, ju,q is sent to the 
server. 

In step 126 the server determines whether ft EQ and q 
£S PK . If either // or q $$ PK , then the server rejects 
authentication. Otherwise, in step 128 the server calculates 
parameter p' as a random hash fuiction H of parameters 
(PK,m^,n). This step 128 is performed in a manner similar 
to that described above in connection with step 120. In step 
130 the server determines whether F PK (p } ) is an element of 
the message space and if not, then the server rejects 
authentication. If F PK (p 1 ) is an element of the message space 
S PK then authentication continues. In step 132, the server 
calculates a* by decrypting q/F^j^') using the secret key SK 
(where/denotes the inverse of the group operation of the 
public key message space). In step 134 the server calculates 
r as a random hash function h applied to a'. In step 136 the 
server sends r to the client. 

In step 138 the client determines whether F PJ< (p) &> PK 
and r-h(a). Only if both of these conditions are true does the 
client accept the server as authentic. Recall that if ¥ PK (p) 
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g S P/c then the client already decided not to accept the server 
in step 122, but went on with the authentication protocol so 
that an adversary could not gain any information from the 
rejection of authentication at step 122. The test for r«h(a) 
tests whether the server possessed the correct password k. 
Thus, at step 138 the client may reject authentication either 
because F PX (p) $S PK or r*h(a) and the server cannot 
determine for which reason authentication was rejected. If 
the client determines to accept the server in step 138, then 
in step 140 the client calculates t=h'(a), where h' is a random 
hash function. In step 142 the client sends t to the server. 

In step 146 the server determines whether t=h'(a'). If 
t=h'(a') then the server accepts authentication. Otherwise, 
the server rejects authentication. If both the client and server 
have accepted authentication, then in step 144 the client 
computes a session key and in step 148 the server computes 
a session key. The session key acts as a shared secret key and 
is used for subsequent secure communication between the 
client and the server. The use of a secret key in such a 
manner is more efficient for subsequent secure communica- 
tion than the continued use of public key cryptography. In 
one embodiment, the session key K may be calculated by 
both the server and client as a random hash function h" of 
a such that K=h"(a). In an alternate embodiment, the session 
key K may be calculated by both the server and client using 
the Diffie-Hellman protocol with m and fi chosen as Diffie- 
Hellman parameters. As would be apparent to one skilled in 
the art, various alternative techniques may be used to 
generate the session keys. 

Thus, the protocol described in conjunction with FIGS. 
1A-1B will provide for mutual authentication of a client and 
a server using a public key encryption scheme which is 
usable as defined above. The protocol described in conjunc- 
tion with FIGS. 1A-1B assumed that the server possessed 
and stored the password jt. One potential problem with such 
a protocol is that a security compromise of server storage 
may allow an adversary to obtain the passwords of clients. 
In order to protect against such an occurrence, we now 
describe a second embodiment of the invention in which the 
server does not possess the password ji, but instead stores a 
value X which is a function of the password jt and a salt 
value. The salt value is a publicly known value which is used 
to prevent dictionary attacks on multiple passwords at the 
same time by forcing an adversary to perform separate 
dictionary attacks for each salt value. The value X is 
supplied to the server by the client, and thus, the server only 
knows X and cannot determine Jifrom knowledge of X, The 
client computes X as X=g*, where g is a generator in some 
group where the discrete log is difficult to compute, x=H' 
(jt,salt), and H' represents a one way random hash function. 
In a manner similar to that described above in connection 
with the first embodiment shown in FIG. 1, the server 
generates public key/secret key pairs (PK, SK) in accor- 
dance with the particular public key encryption scheme 
being used. 

The protocol in accordance with the second embodiment 
of the invention will now be described in conjunction with 
FIGS. 2A-2B. The client initiates the protocol in step 205 by 
sending the client's username to the server. In step 210 the 
server generates m as a random element of Q. In step 212 the 
server retrieves from storage X and salt associated with the 
username received in step 205. In step 214 the server sends 
m, PK and salt to the client. In step 216 the client determines 
whether the m received from the server in step 214 is in the 
set Q and whether PK is in the testable superset e'. If either 
of the tests is false, then the client rejects authentication. 
Otherwise, authentication continues and in step 218 the 
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client calculates x=H'(jt,salt) using the salt received from the 
server in step 214, and where H* is a random hash function. 
In step 220, the client sets parameter pi to be a random 
element of the set Q, and in step 222 the client sets 
parameter a to be a random element of the message space 5 
S^. In step 224 the client calculates parameter p as a 
random hash function H of parameters (PK,m,^,g*). This 
step 224 is similar to step 120 of the first embodiment, 
except in this second embodiment, instead of using the 
password jt as one of the parameters in determining p, a 10 
function of the password ji, namely g*, is used as one of the 
parameters instead. Steps 226, 228, and 230 then proceed as 
described above in conjunction with steps 122, 124, and 126 
respectively. 

In step 232 the server calculates parameter p' as a random 15 
hash function H of parameters (PK,m,/i,X). This step is 
similar to step 128 of the first embodiment, except in step 
232, since the server does not know jt, it instead uses X as 
a parameter of the hash function. Steps 234, 236, and 238 
proceed as described above in conjunction with steps 130, 20 
132, and 134 respectively. In step 240 y is chosen as a 
random element of the set W, where W represents a set of 
possible exponents of g resulting in a sufficiently large set of 
distinct g v values. In step 242 y is set to g Y . In step 244 the 
server sends r and y to the client. Step 246 proceeds as 25 
described above in conjunction with step 138. In step 248 
the client calculates t«h'(a,y*), and in step 250 the client 
sends t to the server. 

In step 254 the server determines whether t=h' (a', X 7 ). If 
t=h' (a 1 , X Y ) then the server accepts authentication. 30 
Otherwise, the server rejects authentication. If both the 
client and server have accepted authentication, then in step 
252 the client computes a session key and in step 256 the 
server computes a session key. 

The first and second embodiments of the invention, 35 
described above in conjunction with FIGS. 1A-1B and 
2A-2B respectively, describe authentication protocols for 
use with a public key encryption scheme which satisfies the 
requirement of being usable, as described above. One such 
usable public key encryption scheme is the RSA public key 40 
encryption scheme with parameters chosen in accordance 
with certain restrictions as described below. We now 
describe third and fourth embodiments of the invention. The 
third embodiment utilizes RSA as the public key encryption 
scheme with a stored password k at the server. The fourth 45 
embodiment utilizes the RSA public key encryption scheme 
with a value X stored at the server, where X is a function of 
the password jt and a salt value. Thus, embodiments three 
and four are the RSA specific embodiments corresponding to 
embodiments one and two respectively. 50 

The third embodiment of the invention will now be 
described in conjunction with FIGS. 3A-3B. In the RSA 
public key encryption scheme, a public key PK is made up 
of two parameters (N, e) and a secret key SK is made up of 
two parameters (N, d). In a usable form of the RSA public 55 
key encryption scheme, the public key PK (N,e) is chosen 
such that N is large, and e is guaranteed to have the property 
that anyone knowing (N,e) can easily test that for any prime 
factor r of N, the greatest common divisor of e and (r^l) is 
1. Some suitable methods to accomplish this are described 60 
below. It is assumed that the server has generated an 
appropriate (PK, SK) pair prior to initiation of the protocol. 
In step 302 the server generates m as a random element of 
Q. In step 304 the server transmits m, N, and e, to the client. 
As described above in conjunction with step 114 of FIG. 1A, 65 
the client must next determine whether m and the private key 
PK received from the server were chosen in an appropriate 



manner to protect against the adversary choosing these 
values in a manner which would allow it to learn some 
information about the password Jt. Thus, in step 306 the 
client determines whether the m received from the server in 
step 112 is in the set Q and whether PK is in the testable 
superset e' (as defined above). In an RSA implementation, 
one way to determine whether PK is in the testable superset 
e f is to determine whether N and e satisfy the following 
conditions: 

N e[2'- 2 ,2']; 

e E[2',2 /+I ] and 
e is prime. 

If N and e satisfy all of the above conditions, then PK Ee\ 
These conditions include tests of whether N is sufficiently 
large (by determining whether N is within the range 2 1 ' 2 to 
2 1 ) and whether e is greater than N (by determining whether 
e is within the range 2 l to 2 /+1 ). If any of the conditions 
shown in step 306 of FIG. 3A are false, then authentication 
is rejected. Otherwise, the protocol continues with step 308. 
It is noted that there is another alternative test to determine 
whether PK Ee' in an RSA embodiment. The alternative test 
is to determine whether the following conditions are satis- 
fied: 

N mod e is not divisible by N; and 
e is prime. 

If N and e satisfy all of these conditions, then PK Ee'. 

It is noted that there are other tests which could be used 
to determine whether PK Ee'in an RSA specific embodi- 
ment. For example, instead of testing whether e is prime, e 
could be a fixed publicly known value and e can be tested to 
confirm that it equals the fixed value. One skilled in the art 
would be able to implement other tests to determine whether 
PK Ee' in an RSA specific embodiment. 

Steps 308, 310, 312 proceed as described above in con- 
junction with steps 116, 118, 120 of FIG. 1A respectively. It 
is noted that the computation in step 120 (FIG. 1) is the same 
as that shown in step 312 (FIG. 3A) with the general PK of 
FIG. 1 being replace by N and e in the RSA specific 
implementation of FIGS. 3A-3B. The next test is to deter- 
mine whether F Pje (p) is an element of the message space of 
the RSA public key (i.e. F^p) ES P/C ). In the RSA specific 
embodiment, this may be accomplished by determining 
whether the greatest common divisor (gcd) of p and N equals 
1. If gcd(p, N)=l, then F PK &) ES PK and in step 314 the 
client calculates q=(p a e ) mod N. If gcd(p, N>1 then F PK (v) 
ES PK and therefore authentication should be rejected. 
However, as described above in conjunction with step 122 of 
FIG. 1A, it is undesirable to terminate authentication at this 
point because doing so may allow an adversary server to 
gain some knowledge of the password re. Therefore, it is 
desirable that the client continue the protocol with the server, 
even if the client has decided that it will reject authentica- 
tion. Thus, if the test in step 314 is true, then the client sets 
q to a substantially random element of the message space by 
setting q=a. In step 316 the client transmits fit,q to the server. 

In step 318 the server determines whether fi EQ and q 
ES PK . The test of whether q ES FK (i.e., q is an element of 
the message space of the RSA public key) is determined by 
testing whether gcd(q, N)=l. If either p £ Q or gcd(q, N)*l, 
then the server rejects authentication. Otherwise, in step 320 
the server calculates parameter p' as a random hash function 
H of parameters (N,e,m,u,jT.). In step 322 the server deter- 
mines whether F^j^') is an element of the message space of 
the RSA public key by determining whether gcd(p', N)-l. If 
gcd(p', N)*l then F^j^') is not an element of the message 
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space of the RSA public key and the server rejects authen- 1. There is a rare occurrence, such as some randomly 

tication. If gcd(p', N>1 then F PA (p') is an element of the chosen values collide (that is, are equal). This is shown 

message space of the RSA public key and authentication to occur with very low probability, say |3. 

continues. In step 324 the server performs RSA decryption 2. There is an event in which the simulator can deduce the 

on (q/p 1 ). Steps 326 through 340 proceed in a manner similar 5 decryption to the ciphertext with non-negligible prob- 

to steps 134 through 148 of FIG. IB respectively. It is noted ability. 

that since this third embodiment is RSA specific, the test in 3. None of the above. In this case, we prove directly that 

step 330 to determine whether F PK (p) eS PK (corresponding the adversary has at most a 
to step 138 in FIG, IB), is performed by determining 

whether gcd(p, N)=l. io I 

In a fourth embodiment of the invention, which will be d 
described in conjunction with FIGS. 4A-4B, a server stores 

a value X which is a function of the password % and a salt probability of breaking the protocol, where v is the number 

value. This is similar to the second embodiment. However, of active "spoofing" attacks and d is the number of possible 

the second embodiment described a protocol using any 15 passwords. 

usable public key encryption scheme. This fourth embodi- Now consider an adversary that breaks the protocol with 

ment uses RSA as the public key encryption scheme. Refer- probability 

ring now to FIG. 4A, in step 402 the client initiates the 

protocol by sending a username to the server. In step 404 the v + ^ 

server generates m as a random element of Q. In step 406 the 20 d 

server retrieves from storage X and salt associated with the 

usemame received in step 402. In step 408 the server sends for non-negligible e. (Informally, this means that the adver- 

m, N, e, and salt to the client. In step 410, the client sary can break tne pro tocol with significantly more prob- 

determines whether the m received from the server in step ability that simply guessing passwords and attempting to 

408 is in the set Q and whether the public key, N and e, are 25 login witn eacn one? wn i cn we claim is impossible.) Using 

in the testable superset e'. In this RSA specific embodiment, mis adversary we will be able to construct an algorithm A 

the test in step 410 of whether the public key is in the mat w j|i ia ^ & an encryption function and ciphertext as input 

testable superset e' is the same as the test in step 306 and decrypt the ciphertext with non-negligible probability. A 

described in conjunction with FIG. 3A (or the alternative ^ mn tne adversary against the simulator. Let E a , ^ and 

tests described above in conjunction with step 306). In steps 30 ^ be me mree even ts described above, and let B be the 

412, 414, and 416 the client generates parameters x^,a as event tnat me adversary breaks the protocol. From the above 

described above in connection with steps 218, 220, and 222 discussion, one can see that 
of FIG. 2A respectively. In step 418 the client calculates 

parameterp as a random hash function H of parameters v 

(N,e,m,a,g*). Next, in step 420, the client determines 35 ? +^WsP^i) + ^aEi) = 

whether F^) eS PK by determining whether gcd(p, N)-l, Pr{Ei) + Pr{B A Et A El) + PfiB ^ 2 A £ l} * 

and generates parameter q as appropriate as described above 

in conjunction with step 314 of FIG. 3A. The client then p«eo + P>iE 2 ) + Pr[B * E 3 ) = 

transmits //,q to the server in step 422. Pr ^ E ^ + p r {Et) + Pr{B | £ 3 ) ■ Pr(E 3 ) * 

In step 424 the server determines whether fx 6EQ and q 40 

eS PK . The test of whether q eS PK is determined by testing PHE ,) + Pr(E 2 ) + PKB | £ 3 ) z/3+Pr(E 2 ) + (-) 
whether gcd(q, N)=l. If either $Q or gcd(q, N)*l, then the 
server rejects authentication. Otherwise, in step 426, the 

server calculates parameter p' as a random hash function H and thus Pr(E 2 )^e-(3, which is non-negligible. Therefore A 

of parameters (N,e,m^,X). Steps 428, 430, 432 then proceed 45 can decrypt the ciphertext with non-negligible probability, 

in a manner similar to steps 322, 324, 326 of FIGS. 3A-3B which contradicts the security of the encryption function, 

respectively, and steps 434, 436 proceed in a manner similar The foregoing Detailed Description is to be understood as 

to steps 240, 242 of FIG. 2B respectively, bein g in ever Y respect illustrative and exemplary, but not 

The server transmits r,y to the client in step 438. Steps 440 restrictive, and the scope of the invention disclosed herein is 

through 450 proceed in a manner similar to steps 246 so not to be determined from the Detailed Description, but 

through 256 of FIG. 2B respectively, with the test of whether rather from the claims as interpreted according to the full 

Fp*(p) eS P/c of step 440 being performed in the RSA breadth permitted by the patent laws. It is to be understood 

specific manner by testing whether gcd(p, N)=l. that the embodiments shown and described herein are only 

The inventors have proven that a mutual authentication illustrative of the principles of the present invention and that 

protocol in accordance with the present invention is as 55 various modifications may be implemented by those skilled 

secure as the underlying public key encryption scheme. in the art without departing from the scope and spirit of the 

Thus, in the RSA specific embodiments, the inventors have invention, 

proven that the protocol is as secure as the RSA encryption We claim: 

scheme. An outline of the proof follows. 1. A method for mutual network authentication between a 

To prove that the present invention is a secure mutual 60 client and a server utilizing a public key encryption scheme 

authentication protocol, we give a reduction argument from comprising the steps, performed at said client, of: 

the security of the protocol to the security of the encryption receiving a public key from said server; 

function used. Specifically, we provide a simulator which determining whether said public key is an element of a 

takes an encryption function and ciphertext as input, and testable superset of the set of all public keys of said 

simulates the protocol with a randomly chosen password 65 public key encryption scheme; and 

against an adversary, such that one of the following events (i) if said public key is not an element of said testable 

occurs: superset then rejecting authentication; or 
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(ii) if said public key is an element of said testable 
superset then performing the steps of: 
generating a parameter p as a function of at least said 

public key and a password; 
determining whether the public key space mapping 5 
function, F w applied to p, F PJC (p), & an element 
of the message space of said public key; 
if Fpj^p) is not an element of the message space of said 
public key, then: 

setting a parameter q to a substantially random element 1Q 

of the message space of said public key; and 
transmitting q to said server. 

2. The method of claim 1 wherein p is further generated 
as a function of at least a parameter m received from said 
server. 

3. The method of claim 2 wherein p is further generated 
as a function of at least a substantially random number p. 

4. The method of claim 1 further comprising the steps, 
performed at said client, of: 

if said public key is an element of said testable superset 20 
then performing the steps of: 

generating a parameter p as a function of at least said 

public key and a password; 
determining whether the public key space mapping 

function, , applied to p, F^^), is an element of 2$ 

the message space of said public key; 
if ¥ P xfe>) is an element of the message space of said 

public key then: 

generating a parameter q by encrypting a substan- 
tially random element of the message space of said 3Q 
public key using said public key and performing 
the group operation of the public key message 
space on the result and F^p); and 

transmitting q to said server. 

5. The method of claim 4 wherein p is further generated 35 
as a function of at least a parameter m received from said 
server. 

6. The method of claim 5 wherein p is further generated 
as a function of at least a substantially random number /*. 

7. The method of claim 6 further comprising the step of: 4Q 
generating a session key using the Diffie-Hellman proto- 
col with m and n as parameters. 

8. The method of claim 1 further comprising the steps, 
performed at said client, of: 

if said public key is an element of said testable superset 45 
then performing the steps of: 

generating a parameter p as a function of at least said 

public key and a function of a password; 
determining whether the public key space mapping 
function, F PK , applied to p, F FJt (p), is an element of 50 
the message space of said public key; 
if Fpj^p) is not an element of the message space of said 
public key, then setting a parameter q to a substantially 
random element of the message space of said public 
key; and 55 
transmitting q to said server. 

9. The method of claim 8 wherein said function of a 
password is a one way function of a hash of the password. 

10. The method of claim 8 wherein p is further generated 

as a function of at least a parameter m received from said 60 
server. 

11. The method of claim 10 wherein p is further generated 
as a function of at least a substantially random number 

12. The method of claim 1 further comprising the steps, 
performed at said client, of: 65 

if said public key is an element of said testable superset 
then performing the steps of: 
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generating a parameter p as a function of at least said 

public key and a function of a password; 
determining whether the public key space mapping 
function, V PK , applied to p, F FK (p) y is an element of 
the message space of said public key; 
if F PK ($) is an element of the message space of said 
public key then: 

generating a parameter q by encrypting a substan- 
tially random element of the message space of said 
public key using said public key and performing 
the group operation of the public key message 
space on the result and F P/c (p); and 
transmitting q to said server. 

13. The method of claim 12 wherein said function of a 
password is a one way function of a hash of the password. 

14. The method of claim 12 wherein p is further generated 
as a function of at least a parameter m received from said 
server. 

15. The method of claim 14 wherein p is further generated 
as a function of at least a substantially random number fi. 

16. The method of claim 15 further comprising the step of: 
generating a session key using the Diffie-Hellman proto- 
col with m and fa as parameters. 

17. A method for mutual network authentication between 
a client and a server comprising the steps, performed at said 
server, of: 

transmitting a public key of a usable public key encryp- 
tion scheme to a client wherein said public key is an 
element of a testable superset of the set of all public 
keys of said usable public key encryption scheme; and 
receiving, as a parameter q from said client, an element of 
the message space of said public key; wherein if the 
public key space mapping function F PK applied to a 
parameter p, F^p), where p is generated at said client 
as a function of at least said public key and a password, 
is not an element of the message space of said public 
key then: 

receiving as parameter q a substantially random ele- 
ment of the message space of said public key. 

18. The method of claim 17 wherein, if the public key 
space mapping function, F PK , applied to a parameter p, 
F PX (p), where p is generated at said client as a function of 
at least said public key and a password, is an element of the 
message space of said public key then: 

receiving as parameter q the result of the group operation 
of the public key message space on a public key 
encryption of a substantially random element of the 
public key message space and F PA (p). 

19. The method of claim 17 wherein, if the public key 
space mapping function, F^, applied to a parameter p, 
Fp/e(p)> where p is generated at said client as a function of 
at least said public key and a function of a password, is not 
an element of the message space of said public key then: 

receiving as parameter q a substantially random element 
of the message space of said public key. 

20. The method of claim 19 wherein said function of a 
password is a one way function of a hash of the password. 

21. The method of claim 17 wherein, if the public key 
space mapping function, F PK , applied to a parameter p, 
F PX (p), where p is generated at said client as a function of 
at least said public key and a function of a password, is an 
element of the message space of said public key then: 

receiving as parameter q the result of the group operation 
of the public key message space on a public key 
encryption of a substantially random element of the 
public key message space and F PiC (p). 
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22. The method of claim 21 wherein said function of a 
password is a one way function of a hash of the password. 

23. The method of claim 17 wherein said public key 
encryption scheme is RSA and wherein said public key 
comprises parameters N and e, and wherein said public key 5 
is chosen by said server such that: 

N is greater than a value; 
e is greater than N; and 

e is prime. 10 

24. The method of claim 17 wherein said public key 
encryption scheme is RSA and wherein said public key 
comprises parameters N and e, and wherein said public key 
is chosen by said server such that: 

N is within a value range; 
e is within a value range; and 
e is prime. 

25. The method of claim 17 wherein said public key 
encryption scheme is RSA and wherein said public key 
comprises parameters N and e, and wherein said public key 
is chosen by said server such that: 

e is a predetermined value; and 
N is within a value range. 

26. A method for mutual network authentication between 
a client and a server utilizing the RSA encryption scheme 
comprising the steps, performed at said client, of: 

receiving an RSA public key (N, e) from said server; 

determining if said RSA public key (N, e) is an element 
of a testable superset of the set of all public keys of said 
RSA encryption scheme, wherein in said step of deter- 
mining 

(i) if said RSA public key (N, e) is an element of a 
testable superset of the set of all public keys of said 
RSA encryption scheme comprises the steps, per- 
formed at said client, of: 
determining whether: 

N is greater than a value; 
e is greater than N; and 
e is prime; or 

(ii) if said RSA public key (N, e) is not an element of 
said testable superset then rejecting authentication. 

27. The method of claim 26 wherein said step of deter- 
mining if said RSA public key (N, e) is an element of a 
testable superset of the set of all public keys of said RSA 45 
encryption scheme comprises the steps, performed at said 
client, of: 

determining whether: 

N is within a value range; 
e is within a value range; and 
e is prime. 

28. The method of claim 26 wherein said step of deter- 
mining if said RSA public key (N, e) is an element of a 
testable superset of the set of all public keys of said RSA 
encryption scheme comprises the steps, performed at said 55 
client, of: 

determining whether; 
e is a predetermined value; and 
N is within a value range. 

29. The method of claim 26 further comprising the steps, 
performed at said client, of: 

if said RSA public key (N, e) is an element of a testable 
superset of the set of all public keys of said RSA 
encryption scheme, then performing the steps of: 
generating a parameter p as a function of at least said 
RSA public key (N, e) and a password; 
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determining whether the public key space mapping 
function, F PK , applied to p, F P ^(p), is an element of 
the message space of the RSA public key; 

if F^fy) is not an element of the message space of the 
RSA public key then: 

setting a parameter q to a substantially random 
element of the message space of the RSA public 
key; and 

transmitting q to said server. 

30. The method of claim 29 wherein said step of deter- 
mining whether F PJ< (p) is an element of the message space 
of the RSA public key comprises the step of: 

determining if the greatest common divisor of p and N is 
equal to 1. 

31. The method of claim 29 wherein p is further generated 
as a function of at least a parameter m received from said 
server. 

32. The method of claim 31 wherein p is further generated 
as a function of at least a substantially random number ju. 

33. The method of claim 26 further comprising the steps, 
performed at said client, of: 

if said RSA public key (N, e) is an element of a testable 
superset of the set of all public keys of said RSA 
encryption scheme, then performing the steps of: 
generating a parameter p as a function of at least said 

RSA public key (N, e) and a password; 
determining whether the public key space mapping 

function, F PK9 applied to p, F PJC (p), is an element of 

the message space of the RSA public key; 
if F PJS (p) is an element of the message space of the RSA 

public key then: 

generating a parameter q as q=(P a 0 mod N > where 
a is a substantially random element of the message 
space of the RSA public key; and 

transmitting q to said server. 

34. The method of claim 33 wherein said step of deter- 
mining whether F PX (p) is an element of the message space 
of the RSA public key comprises the step of: 

determining if the greatest common divisor of p and N is 
equal to 1. 

35. The method of claim 33 wherein p is further generated 
as a function of at least a parameter m received from said 
server. 

36. The method of claim 35 wherein p is further generated 
as a function of at least a substantially random number 

37. The method of claim 36 further comprising the step of: 
generating a session key using the Diffie-Hellman proto- 
col with m and ju as parameters. 

38. The method of claim 26 further comprising the steps, 
performed at said client, of: 

if said RSA public key (N, e) is an element of a testable 
superset of the set of all public keys of said RSA 
encryption scheme, then performing the steps of: 
generating a parameter p as a function of at least said 

RSA public key (N, e).and a function of a password; 
determining whether the public key space mapping 

function, F^, applied to p, F^p), is an element of 

the message space of the RSA public key; 
if F P #(p) is not an element of the message space of the 

RSA public key then: 

setting a parameter q to a substantially random 
element of the message space of the RSA public 
key; and 

transmitting q to said server. 

39. The method of claim 38 wherein said function of a 
password is a one way function of a hash of the password. 
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40. The method of claim 38 wherein said step of deter- 
mining whether F PJ< (p) is an element of the message space 
of the RSA public key comprises the step of: 

determining if the greatest common divisor of p and N is 
equal to 1. 5 

41. The method of claim 38 wherein p is further generated 
as a function of at least a parameter m received from said 
server. 

42. The method of claim 41 wherein p is further generated 
as a function of at least a substantially random number fi. 

43. The method of claim 26 further comprising the steps, 
performed at said client, of: 

if said RSA public key (N, e) is an element of a testable 
superset of the set of all public keys of said RSA 15 
encryption scheme, then performing the steps of: 
generating a parameter p as a function of at least said 

RSA public key (N, e) and a function of a password; 
determining whether the public key space mapping 

function, F PK , applied to p, F^^), is an element of 20 

the message space of the RSA public key; 
if F PK (p) is an element of the message space of the RSA 

public key then: 

generating a parameter q as q^^-a^) mod N, where ^ 
a is a substantially random element of the message 
space of the RSA public key; and 

transmitting q to said server. 

44. The method of claim 43 wherein said function of a 
password is a one way function of a hash of the password. 30 

45. The method of claim 43 wherein said step of deter- 
mining whether F PK (jp) is an element of the message space 
of the RSA public key comprises the step of: 

determining if the greatest common divisor of p and N is 
equal to 1. 35 

46. The method of claim 43 wherein p is further generated 
as a function of at least a parameter m received from said 
server. 

47. The method of claim 46 wherein p is further generated 

as a function of at least a substantially random number p. 40 

48. The method of claim 47 further comprising the step of: 
generating a session key using the Diffie-Hellman proto- 
col with m and /i as parameters. 

49. A method for mutual authentication between a client 
and a server utilizing a public key encryption scheme 
comprising the steps of: 

said server transmitting a public key to said client; 
said client determining whether said public key is an 

element of a testable superset of the set of all public 50 

keys of said encryption scheme; and 

(i) if said client determines that said public key is not 
an element of said testable superset, then said client 
rejecting authentication; or 

(ii) if said client determines that said public key is an 55 
element of said testable superset then: 

said client generating a parameter p as a function of 
at least said public key and a password; and 

said client determining whether the public key space 
mapping function, Fp^, applied to p, F FJ( (p), is an 60 
element of the message space of said public key. 

50. The method of claim 49 wherein: 

if said client determines that F P/c (p) is an element of the 

message space of said public key then: 

said client generating parameter q by encrypting a 65 
substantially random element a of the message space 
of said public key using said public key and per- 



forming the group operation of the public key mes- 
sage space on the result and F P #(p); and 
transmitting q to said server. 

51. The method of claim 50 further comprising the step of: 
if said client determines that F PX fo) is not an element of 

the message space of said public key, then said client 
setting parameter q to a substantially random element 
of the message space of said public key. 

52. The method of claim 50 further comprising the steps 
of: 

said server determining whether q is an element of the 

message space of said public key; 
if said server determines that q is not an element of the 

message space of said public key, then said server 

rejecting authentication; 
if said server determines that q is an element of the 

message space of said public key, then said server 

generating a parameter p' as a function of at least said 

public key and said password; 
said server determining whether the public key space 

mapping function, F PK , applied to p', F^p'), is an 

element of the message space of said public key; 
if said server determines that F^p') is not an element of 

the message space of said public key, then said server 

rejecting authentication; 
if said server determines that F Pje (p') is an element of the 

message space of said public key, then said server: 

generating a parameter a' by performing the inverse of 
the group operation of the public key message space 
on q and Fp^') and decrypting the result using a 
secret key corresponding to said public key; 

generating r=h(a'); and 

transmitting r to said client 

53. The method of claim 52 further comprising the steps 



of: 



said client determining: 

a) if F^p) is an element of the message space of said 
public key; and 

b) if 

if a) or b) is not true, then said client rejecting authenti- 
cation; 

if a) and b) are true, then said client generating t=h'(a) and 
transmitting t to said server. 

54. The method of claim 53 further comprising the steps 

f: 

said server determining if t=h'(a); 

if t«h'(a') then said server accepting authentication; 

if t^h'(a') then said server rejecting authentication. 

55. The method of claim 54 further comprising the steps 



of: 



of: 



if said server and said client accept authentication, then 
said server and said client computing session keys for 
subsequent secure communication. 

56. The method of claim 49 further comprising the steps 



of: 



if said client determines that said public key is an element 
of said testable superset then: 

said client generating a parameter p as a function of at 
least said public key and a function of a password; 
and 

said client determining whether the public key space 
mapping function F PK applied to p, F PK (p), is an 
element of the message space of said public key. 
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57. The method of claim 56 wherein: 

if said client determines that F^^p) is an element of the 

message space of said public key then: 

said client generating parameter q by encrypting a 
substantially random element a of the message space 
of said public key using said public key and per- 
forming the group operation of the public key mes- 
sage space on the result and F Pje (p); and 

transmitting q to said server. 

58. The method of claim 57 further comprising the step of: 
if said client determines that F^^) is not an element of 

the message space of said public key, then said client 
setting parameter q to a substantially random element 
of the message space of said public key. 

59. The method of claim 57 further comprising the steps 



said server determining whether q is an element of the 

message space of said public key; 
if said server determines that q is not an element of the 

message space of said public key, then said server 

rejecting authentication; 
if said server determines that q is an element of the 

message space of said public key, then said server 

generating a parameter p' as a function of at least said 

public key and a function of said password; 
said server determining whether the public key space 

mapping function, F^, applied to p', ¥ PX fp% is an 

element of the message space of said public key; 
if said server determines that F^p') is not an element of 

the message space of said public key, then said server 

rejecting authentication; 
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if said server determines that Fj^p') is an element of the 
message space of said public key, then said server: 
generating a parameter a 1 by performing the inverse of 
the group operation of the public key message space 
on q and F PJ ^p) and decrypting the result using a 
secret key corresponding to said public key; 
generating r=h(a'); and 
transmitting r to said client. 

60. The method of claim 59 further comprising the steps 

f: 

said client determining: 

a) if F^p) is an element of the message space of said 
public key; and 

b) if r«h(a) 

a) or b) is not true, then said client rejecting authentica- 
tion; 

if a) and b) are true, then said client generating t=h'(a) and 
transmitting t to said server. 

61. The method of claim 60 further comprising the steps 



of: 
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said server determining if t-h'fa'); 

if t=h , (a l ) then said server accepting authentication; 

if t*h , (a t ) then said server rejecting authentication. 

62. The method of claim 61 further comprising the steps 



of: 



30 



if said server and said client accept authentication, then 
said server and said client computing session keys for 
subsequent secure communication. 
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